Module 11
Spring 2010 Closure
Compiled by Greg Kinney
“MUDDIEST ITEMS” in this module:
Question:
The least clear thing I learned from this module was regarding meetings on Page 505.  The fifth bullet states “…do not report votes on controversial matters.”  It seems you would always want to report votes on controversial matters to have record of staff/manager/agency opinion.  If this information does not make it on record, then there’s no background to the issue as to why the decision was made the way it was. 
Answer:
I think that the record needs to reflect the substance of the issue, some salient points that were considered, and the resolution, if there was one.  (If there wasn’t, the record should reflect accurately what the viewpoints were.)  But I agree that if it came down to a vote, reporting of a vote is only going to create lots of questions – such as who voted which way.  It also sows the seeds of future controversy.  Bottom line, there are ways to report accurately on a controversial issue without fanning the flames, and reporting votes (whether by name or just by aggregate numbers) doesn’t achieve that end.

Question:
The muddiest thing from this chapter were some of the calculations, not necessarily the math itself but what information to use for what part of certain equations.  It seems someone subjective as to what information can be used and what costs count for certain parts of the equation.  Maybe I’m just used to hard and fast numbers. 
Answer:
There is some fuzz on the numbers, particularly when you get into estimating % complete.  It’s really hard to estimate in certain kinds of projects.  So this is kind of a black art.  It’s easiest when you get into work that has a predefined schedule of values, and completion of one activity has a defined earned value associated with it based on the bid.  Even then, updating the estimate requires a guess at % complete for the task(s) in progress.
Question:
The muddiest item in this module is that since we can calculate (estimate) the CV and SV, especially the SV, we will know the project proceeded is behind/delay or ahead of the schedule. Why should we need to know the TV? 
Answer:
Notwithstanding the fact that SV stands for schedule variance, it really doesn’t give you a projection of how many days or weeks we are away from completion.  It is actually just the difference between how much value was earned vs. how much value was planned to be earned as of right now.  The time variance is the difference in the time scheduled for work to be performed vs. how long it actually took.  In my experience, I never hear people use the term “time variance” but they always talk about how far behind schedule the project is.  So, even if they aren’t formally calculating time variance, in fact that is the thing that people are discussing and relating to.

Question:
The muddiest part the websites first comments about the monitoring and controlling cycle. I thought from reading that, there was some set of standardized rules that could be applied to find the best monitoring and controlling system. But it seems that the best system is whatever gives the PM the reports consistent with the project objectives. 
Answer:
I agree.  A one size fits all approach won’t work well; it has to be customized.

Question:
If I have to pick one “muddy” item, it would be the definition of “Software” in the Glossary at the end of the chapter:  “The instructions for running a computer.”  I always thought that software was a program or application that was run on a computer… not an instruction booklet (sarcastic).